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Background 

This invention relates to synchronizing databases. 

20 Databases are collections of data entries which are 

organized, stored, and manipulated in a manner specified by 
applications known as database managers (hereinafter also 
referred to as "Applications"; the term "database" will also 
refer to the combination of a database manager and a 

2 5 database proper) . The manner in which database entries are 
organized in a database is known as its data structure. 

There are generally two types of database managers. 
First are general purpose database managers in which the 
user determines (usually at the outset, but subject to 

30 future revisions) what the data structure is. These 

Applications often have their own programming language and 
provide great flexibility to the user. Second are special 
purpose database managers that are specifically designed to 
create and manage a database having a preset data structure. 



• # 

Examples of these special purpose database managers are 
various scheduling, diary, and contact manager Applications 
for desktop and handheld computers. Database managers 
organize the information in a database into records, with 
5 each record made up of fields. Fields and records of a 
database may have many different characteristics depending 
on the database manager's purpose and utility. 

Databases can be said to be incompatible with one 
another when the data structure of one is not the same as 

10 the data structure of another, even though some of the 
content of the records is substantially the same. For 
example, one database may store names and addresses in the 
following fields: FIRST_NAME, LAST_NAME, and ADDRESS. 
Another database may, however, store the same information 

15 with the following structure: NAME, STREET_NO., 

STREET_NAME, CITY_STATE, and ZIP. Although the content of 
the records is intended to contain the same kind of 
information, the organization of that information is 
completely different. 

2 0 Often users of incompatible databases want to be 

able to synchronize them with one another. For example, in 
the context of scheduling and contact manager Applications, 
a person might use one Application on the desktop computer 
at work while another on his handheld computer or his laptop 

2 5 computer while away from work. It is desirable for many of 
these users to be able to synchronize the entries on one 
with entries on another. The U.S. patent and copending 
patent application of the assignee hereof, Puma Technology, 
Inc. of St. Jose, California (U.S. Patent No. 5,392,390 

30 (hereinafter, "the '390 patent"); U.S. Application, Serial 
No. 08/371,194, filed on January 11, 1995, incorporated by 
reference herein) show two methods for synchronizing 
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incompatible databases and solving some of the problems 
arising from incompatibility of databases. 

Synchronization of two incompatible databases often 
requires comparison of their records so that they can be 
5 matched up prior to synchronization. This may require 

transferring records in one database from one computer to 
another. However, if the data transfer link between the two 
computers is slow, as for example is the case with current 
infrared ports, telephone modem, or small handheld 
10 computers, such a transfer increases the required time for 
synchronization by many folds. 

Summary 

In one aspect, the invention features a computer 
implemented method for synchronizing a first database 

15 located on a first computer and a second database located on 
a second computer. At the first computer, it is determined 
whether a record of the first database has been changed or 
added since a previous synchronization, using a first 
history file located on the first computer comprising 

20 records representative of records of the first database at 
the completion of the previous synchronization. If the 
record of the first database has not been changed or added 
since the previous synchronization, the first computer sends 
the second computer information which the second computer 

25 uses to identify the record of the first database to be 
unchanged . 

The embodiments of this aspect of the invention may 
include one or more of the following features. 

A second history file may be located on the second 
30 computer. The second history file contains records 

representative of records of the first database at the 
completion of the previous synchronization, where one of the 




representative records represents the record of the first 
database determined to be unchanged. Then, at the second 
computer, a synchronization of the second and first 
databases is performed using the one of the representative 
5 records. 

The information sent from the first computer to the 
second computer can be used to locate the one of the 
representative records in the second history file. The 
second history file can store information in relation to the 

10 representative records and the one of the representative 
records in the second history file can be identified from 
that stored information. Additionally, the information sent 
from the first computer to the second computer can include 
information that matches the information stored in relation 

15 to the one of the representative records in the second 
history files. 

The information sent to the second computer can 
include information identifying records other than the 
unchanged record. It can also include information 

20 identifying the changed record. It can also include 
information identifying the deleted records or added 
records. The information can also include a code based on 
at least a portion of the content of the record of the first 
database. The code may be a hash number. The information 

25 may be a code uniquely identifying the record of the first 
database. Such a code may be one assigned by the first 
database to the records. 

In another aspect, the invention features a computer 
implemented method of identifying a record of a database. A 

3 0 record of the database is read. A code is assigned to the 
record of the database, the code being based on at least a 
portion of the content of the record of the first database. 
The code is then to identify the record at a later time. 
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The embodiments of this aspect of the invention may 
include one or more of the following features. 

The code may be a hash number computed based on at 
least a portion of the content of a record of the first 
5 database. 

The database is stored on a first computer and the 
code is transmitted to a second computer to identify the 
record to an application. 

Advantages of the invention may include one or more 
10 of the following advantages. 

When synchronization is performed using the 
invention, a data transfer link, specially a slow data 
transfer link, is used efficiently, ^since unchanged records 
Q that are typically the majority of thk records in a database 

;E 15 are not transferred between the two computers. Hence, when 

jjjjj 

„p synchronizing two databases on two different computers, the 

time needed to synchronize the two databases is decreased 
Also, when- transmitting data from one computer to 
W another, using a content based code, that requires less 

IU 20 bandwidth for being transmitted and nonetheless identifies a 
=C record, results in a slow data transfer links being used 

more efficiently, 
n The invention may be implemented in hardware or 

I s * software, or a combination of both. Preferably, the 

25 technique is implemented in computer programs executing on 
programmable computers that each include a processor, a 
storage medium readable by the processor (including volatile 
and non-volatile memory and/or storage elements) , at least 
one input device, and at least one output device. Program 
30 code is applied to data entered using the input device to 

perform the functions described above and to generate output 
information. The output information is applied to one or 
more output devices. 
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Each program is preferably implemented in a high 
level procedural or object oriented programming language to 
communicate with a computer system. However, the programs 
can be implemented in assembly or machine language, if 
5 desired. In any case, the language may be a compiled or 
interpreted language. 

Each such computer program is preferably stored on a 
storage medium or device (e.g., ROM or magnetic diskette) 
that is readable by a general or special purpose 

10 programmable computer for configuring and operating the 

computer when the storage medium or device is read by the 
computer to perform the procedures described in this 
document. The system may also be considered to be 
implemented as a computer-readable storage medium, 

15 configured with a computer program, where the storage medium 
so configured causes a computer to operate in a specific and 
predefined manner. 

Other features and advantages of the invention will 
become apparent from the following description of various 

20 embodiments, including the drawings, and from the claims. 

Brief Description of the Drawing 
Figure 1 shows two computers connected via data 
transfer link. 

Figure 2 is a schematic drawing of the various 
25 modules constituting an embodiment. 

Figure 3 is a representation of the host workspace 
data array. 

Figure 4 is pseudocode for the Translation Engine 
Control Module. \ 
3 0 Figure 5 is pseudocode for a remote segment of a 

synchronization program whenNloading records from and 
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unloading records to the remote database, when the database 
assigns uniqu\ IDs. 

Figure \ is pseudocode for a host segment of a 
synchronization program when loading records from and 
5 unloading records oo the remote database, when the database 
assigns unique IDs. \ 

Figure 7 is pseudocode for a remote segment of a 
synchronization program when loading records from and 
unloading records to the remote database, when the database 
10 does not assign unique IDs. \ 

Figure 8 is pseudocode ^for a host segment of a 
synchronization program when loading records from and 
unloading records to the remote dafc^base, when the database 
assigns unique Ids. 

15 Description 

Briefly, referring to Figs. 1 and 2, a 
synchronization program , according to the embodiments 
described here, has a host segment 2 8 and a remote segment 
26 which run on a host computer 20 and a remote computer 22, 
2 0 respectively. The two computer are connected together via a 
data transfer link 24 enabling them to transfer data between 
them. Data transfer link 24 may be a slow data transfer 
link such as a serial infrared links, serial cables, modems 
and telephone lines, or other such data transfer links. A 

2 5 host database 13 and a remote database 14, e.g. scheduling 

databases, are stored on remote computer 22 and host 
computer 20, respectively. 

Generally, in some instances, both computers on 
which the two databases run are capable of running programs 

3 0 other than a database, as in the case of, for example, 

general purpose computers such as desktop and notebook 
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computers, or handheld computers having sufficient memory 
and processing power. In such a case, the synchronization 
program may be distributed between the two computers so as 
to, for example, increase the efficiency of using of a slow 
5 data transfer link between the two machines. 

Briefly, at remote computer 22, remote segment 26 of 
the synchronization program loads records of remote database 
13. Remote segment 26 then determines which records of the 
remote database have been changed/added, deleted or left 

10 unchanged since a previous synchronization. If the remote 
database assigns unique identification codes (i.e. unique 
ID) to its records, remote segment 26 can further 
differentiate between records than have been added and those 
than have been changed since the previous synchronization. 

15 Remote segment 26 uses a remote history file 30 which stores 
data representing or reflecting the records of the database 
at the completion of the previous synchronization. This 
data may be a copy of remote database 13. It may also be 
hash numbers for each of the records of the remote database. 

2 0 If the remote database assigns unique IDs, the remote 

history file may contain those unique IDs together with the 
hash numbers of the records corresponding to the stored 
unique IDs . 

Remote segment 26 sends those records of the remote 

2 5 database that have been changed or added to the host segment 

or the host computer. However, the remote segment does not 
send the unchanged or deleted records to the host computer. 
Instead, the remote segment sends a flag indicating the 
status of the record (e.g. unchanged or changed) and some 

3 0 data or information that uniquely identifies the record to 

the host segment. This data or information may be a hash 
number of all or selected fields in the record at the 
completion of the last synchronization. It may also be the 
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unique ID assigned to the record by the remote database, if 
the database assigns one to its records. 

Host segment 2 8 uses the received information or 
data that uniquely identifies the unchanged record to access 
a record in host history file 19 that corresponds to the 
received information or data. This record contains a copy 
of the data of the remote database record that the remote 
segment found to have been unchanged. Host segment 19 then 
uses this - record to synchronize the databases by comparing 
it to the records of host database 14. After 
synchronization, the remote and host history files and the 
databases are updated. Since the unchanged records which 
typically constitute most of the records of a database are 
not transferred to the host computer, a data transfer link, 
specially a slow data transfer link, is used with increased 
efficiency. 

Be-Jh«r3r3r--des cribo two embodiments of a dlotxito itB4 
synchronization program^J7g - jadrlJr--fi^st describe in general 
terms the_Q3^e^a±T^str^ture of the distributed 
synchroni zati on progra m in reference to Fig s . 2 and 3 which 
is common to both embodiments. WewiJ^t^^ 
the first and-seeendr-embodiments performing a distributed 
"jy^ b^onTzation in t»<* f jajw=Ha^ 4 - 8 . ^ 

_ FM-g. ? <=h^W S f ^e rp1afi/mr .hip b n f.w fi en t iie v^£ious 

modules of an embodir^ 

prfaggaau Translation Engine^^omprj^e^^Control Module 2 
that is responsible for control ling the synchronic 
ar_o. ce .as— by H .-n"S't"ructi ng various modules to perform specific 
tasks on the records of the two da'taBSSHS— being. 



syneh-ron-i-zed^ ThertZeHErol Module 2 also provides data that 

af fect^^he^speci-fl^nspefatTon of the varToIIS^composgfits of 



^h*e— syfiehref^-ation—pr'ogram, such as the name of the 
da t aba s e s being ^ynch-ron-i-zed—a'na user preferences. 
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S ynchronizer 15 has primary—; ges-pon'sl'BiTitv for carrying out 
thi^o-re—sync^ functions. It is a table-driven code 

which is capable of synchronizing var ^oi^^ s e s 

5 whose characteristic control module 2. The 

S ynGhgQgj-^e--CT i n 

detail_in— : Figr^TL/-^ whi-eh— rs a temporary data array used 
"""during the synchronization process. 

A host translator 9 includes two modules: a reader 

10 module 10 which reads the data from the host database 14 and 
an unloader module 10 which analyzes' and unloads records* 
from the host workspace into the host database 14. Remote 
segment 26 'also has similar modules for reading and 
unloading data from the remote database. The remote segment 

15 is designed specifically for interacting with remote, 
database 13. The design of the remote segment is 
specifically based on the record and field structure of the 
remote database and remote database's Application Program 
Interface (API) requirements and limitations and other 

20 characteristics of the remote database. Similarly host 

translator 9 is designed specifically for the host database. 
The remote segment and host translator are not able to 
interact with any other databases or Applications. They are 
only aware of the characteristics of the databases for which 

25 they have been designed. In an alternate embodiment, the 

host translator and the remote segment can be designed as a 
table-driven code, where a general Translator is able to 
interact with a variety of databases based on the parameters 
supplied by, for example, the Control Module 2. It should 

3 0 be noted that the remote segment and host translator may be 
designed in various ways and still perform the tasks set out 
in this embodiment. 
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^J±gw^-j^^^ op o ra ^3re*s£ 
Contr^l^ModTJle^T*^fthe Translation Engine 1. We will use 

lerally describe distributed 
synchronization according to the invent.ip.n^IIIX^oivfc^Ql Module 
2 f irst^ni^i-al"^^ specifies the current user 7 

In step 402, control 
io~st--ftast o r y 



op t i ons to va r 10" as~moduie-s— (-S-t.ep_4^1|^ 
module 2 instructs the Synchronizer to load 
file 19. Synchronizer 15 in response c reates host workspa ce 
16 data array^idj..oad5-4ios1:'~hi story file 19 into host 
10 ^jvorkspace^Ti^ Host history file 19 is a file that was saved 
at the end~~of Ta^TT~sync^ records 
representative of the records of the two database^^t_the 
end of the previous synchronization. Tyipical.Ly^ f --t-he--ho-£ 
history file contaios-a— copY~~o~f the results of the previous 
15 s^nchroni^ synchronized records of the two 

databases^ It should be noted that the~~con^ent_of the 
records of the history file may be limited onlyJ ^o_th&se 
fields tha^-a-re-synrhxonized and the data may be translated 

id stored in a format different than that of the remote 
database^or~~lriTe- 4ioat databas e^ This-data_ can_be used to 



20 

recons t ruct_tji£_^^ 
/^tabase as they were at the end of the previous 
^yn^roirrxa:Hroi^ — The ho o t JaiaJt^aE^fil^. is generally used to 
de t e r m i n e__c h a ng e s— t o— t-h e~ dat3-fra^ 
2 5 l^icfagoni^t j^on and a lso to recreate records not sent from 
the remote segment, as will be describe* 
I £-h^o— hrstrrfy^f iTe~ from a previous syn^h'rondrsartioiLexisf s or 
the^lrserL^chooses to synchronize without using the history 
C^file, in step 402~~the synchrbnizer~aoes- n^feioa^^a^hi s t ory 
3 0 file^ In that case, all the r e c o r d"s~f roTrr-bo t-h-d-at ab aa^ s 
wirr"1re-ix>axie^^ — W e will d escxdbe 
the^resF"oT~rh e op e ration of— the cont r o3 r-modul e as if _,a 
his^&ry-fi-l^—e^ win be used. 
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Once the History File is loaded into the host 
workspace, Control Module 2 instructs host translator 13 to 
load the host database records (step 4 03) . Host Reader 
module 11 of the host Translator reads the host database 
records and sends them to the Synchronizer for writing into 
the host workspace. 




^J^^> l ^ f ^ nt " rn1 Minn H ngfrnrf^ r emote Segment tO 

send the records of the remote databas _e (.step— 404-)-; Remote. 

segffiSHt~-2-G— eeads-j^he^ database records and sends them 

10 to Synchronizer 15 for wriFing~TnKrir^ 

The actions taken by the syn^hr^rLlzex-^nd— ^Q r c m et e segment 



^-iir-response t o_ s t ep— 4G4— w^i-Hr— b~e"~d e s c r i bed' in detail in 
^XefexeJnce_-to---F-i-g-s-^ — 5", 6~ 7 , and "8T~iT^ovrr- 
Q Records in the host workspace are stored according 

S 15 to either the host database or the remote database data 
,p structures. Therefore, as synchronizer 15 receives each 

5 « record, the Synchronizer maps that record using the 

.i — 

— 

O appropriate record map (i.e. either a remote database to 

m host database record map or a host database to remote 

O 2 0 database record map) before writing the record into the next 
'■f available spot in the host workspace. Mapping may be 

performed by other modules, e.g. the remote segment. The 
□ records may also be "translated 11 , i.e. cast into a format 

~ which synchronizer can use (a "translation" method is 

25 described in the '390 patent). For example, a date stored 

as "April 1, 97" may be translated into a format preferred 

by the synchronizer, e.g. "4-1-97". 

Control module 2 then instructs the Synchronizer to 

perform a Conflict Analysis and Resolution ("CAAR") 
3 0 procedure on the records in the host workspace (step 4 05) , 

which procedure is described in detail in the following 

applications of the assignee hereof, Puma Technology, Inc. 

of St. Jose, California, incorporated by reference in their 
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entirety including any appendices: "Synchronization of 
Recurring Records in Incompatible Databases", Serial no. 



, ,. 08/752,490, filed on November 13, 1! 
application - "- r ; "Synchronization of I 



^996 ftercr riaf tor, — " ' 4D8 

)' --f — Databases with Record 

^5 Sanitizing and Intelligent Comparison," Serial no. . 

08/749,926, filed. November 13, 1996 {hereinafter, "'926 
Spfii^ application "y; "Synchronization of Databases with Date 
V Range," Serial no. 08/748,645, filed November 13. 1996 
(horomo-f tor, — 1 1 ' 615 applxiaLion ' " )p Generally, ^ 
10^r^ synchronization is a process of analyzing records from the 

remote database and host database against the records of the 
history file to determine the changes, additions, and 
deletions in each of the two databases since the previous 
synchronization and what additions, deletions, or updates 
15 need be made to the databases to synchronize the records of 
the databases. Briefly, during CAAR, the synchronization 
engine (i.e. the Synchronizer) compares the records in the 
host workspace and determines what synchronizing actions 
should be taken. The synchronization engine processes the 
2 0 records, including comparing them to one another, in order 
to form them into groups of related records. Each of these 
groups may comprise at most one recurring or a group of 
related nonrecurring records from each of the databases and 
history file. After forming these groups from all records 
25 of the two databases, the Synchronizer determines what 

synchronization action should be taken. To do this, the 
Synchronizer compares them, determines their differences, 
and decides what synchronization action is appropriate or 
asks the user what action should be taken. The synchronizer 
30 then associates with that record, the specific "action" 

(e.g. add, update or delete) that must be taken with respect 
to that record in that record's database. During "CAAR" , 
the user may select not to synchronize a particular record 
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with the other database. We will describe below in detail 
the steps performed by the synchronizer and the remote 
segment in response to the output of CAAR as the output 
relates to the remote database. 

Once Synchronizer 15 finishes performing CAAR on the 
records, the records may be unloaded or written into their 
respective databases, including any additions, updates, or 
deletions. However, prior to doing so, the user is asked to 
confirm proceeding with unloading (steps 108-109) . Up to 
this point, neither the databases nor the History File have 
been modified. The user may obtain through the Control 
Module's Graphical User Interface (GUI) various information 
regarding what will transpire upon unloading. 

£ihronign-t-'i-f Sfea 

toiinloa^ — tiieTScorcls are then unloaded in order into 
the hostdataBSBB-; — fe^e-^emot^_dat^ase and the History File. 
The Synchronizer in conjunction with theTios^iri^a^^ and 
j^hg_r^mai^e_-segmeTi^^ the unloading for the database's . 

Synch^x)^^ File and unloads the 

records into it. Control Module T2Tirsr~-±n^^ host 
hranfllahortojinload t hp r<*m rc\* from host workspace 
tHi-^-hos^C^ Following unloading of the host records., 

Control Module2Tn^tr^ the remote 

segment to unload the remote records from the hos^we^J^space 

(s£e£-£Q^ 
to Figs 



We-wxil^aescribe in detail below, in reference 

^tions^ taken by Synchronizer 15 

he host 



5-87"^ 

and remote segment 26 in order to unload data 
workspace— rnTo^tEe^remote database and the update remote 

hisrur y filo 28. Control Modul e 2 n e x t i n s ,^ructj_tlie 

gyn^hrrmiggT- fo rreaf.e a npw History File (step 112) . At 



this point Synchronization is— eempiel^g. 

Referring Lu Figs. — 5 - 8 , — we wi l l now -describe the 
act ions t ake n " by the rem ote segment: in conr^i^a^aoiij^£th the 
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Syncnromzer irr~rcGponGC to - Llie iusliauLiuus fro m control 
module 2in^st^^ remote database 

and "Trr--3^eplA(Ig_t o unloa d the records of the remote database 
from the host workspace. SpecTFTcaliryT — wg^will describe two 
embodiments. In the case o ftjie_Jjj^s£--embod4^ he 
remoted^§^ase-^a-s'Signs unique identification codes (i.e. 
uniquelDS") L o each of i - fc s— ^ecoxds as they are created. In 
the case of the second embodiment^ tTh^^ei^ 
not assign unique IDs t,0— its— a?eeords" F'tg^ 5 — is €he 
psqudecotie~"Toir^^ taken by the remote segment while 

Fig. 6~"Ts" the ps eudocode fo r the s teps -t-akenr-by^t^ e 
SyriG-hff0flM-eTr"tHnihe. case of the second embodiment . 
SimiT^riY~ f ^J ^_. 7 is the pseudocode for the steps taken by 
thgL-remG-fce— segment while Fig. 8 is the pseudocode for the 




s taken by the^ S^mchronjrZ-er--rn"^he case of the first 
t . 

Briefly, the remote segment determines which records 
have been changed/added, deleted or left unchanged since a 
previous synchronization. The remote segment uses a history 
file located on the remote computer ( "remote history file") 
to determine which records may have been changed/added, 
deleted or left unchanged since a previous synchronization. 
The remote segment essentially can translate outputs of any 
database into outputs of a fast synchronization database 
which is a type of database that generally supplies 
information as to which of its records have been changed, 
added, deleted, or left unchanged. Fast synchronization 
databases and an example of a method of synchronizing J:hem 
with other databases is described in detail in the ' 4 9'9r 
Lja. ?fi jc applications. Therefore, for example, this 

method of distributed synchronization may also be 
implemented with any synchronization program that is able to 
synchronize such databases. 
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Generally, the remote segment sends the host 
segment, over the data transfer link, only the content of 
those records that have been changed or newly added. As for 
unchanged records, the history file contains all necessary 
5 information to recreate or synchronize those records, if 
needed. Therefore, it is not necessary to transfer those 
records to the host segment. Only some data or 
identification code that uniquely identifies the record to 
the Synchronizer need be transferred for such a record. 

10 Since the majority of records are typically unchanged 

records, not transferring them over the slow data transfer 
link improves the efficiency of the synchronization process. 

After all necessary information has been transferred 
to the host segment, the Synchronizer synchronizes the 

15 databases. Following synchronization, the host segment 
transfers information necessary to update the remote 
database and the remote history file to the remote segment. 
The remote segment then updates its history file and the 
remote database. 

20 Since both the host and remote segments rely heavily 

on history files to enable distributed synchronization, it 
is important that the host and remote segments use history 
files that correspond to one another, i.e. both contain 
records corresponding to a previous synchronization of the 

2 5 same two databases. In the described embodiment, the remote 

and host history files are named using a common naming 
convention. The name of a file is made up of six 
components : 

1) Name or ID of the host computer, which may be 

3 0 an assigned name such as an assigned GUID in the case of 

operating systems by Microsoft Corporation of Redmond, 
Washington, or UUID in the case of operating systems by Open 
Software Foundation; 
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• 2) Name or ID of the host database application, 
e.g. trademark designations "Lotus Organizer" or "Microsoft 
Schedule*" ; 

3) Name or ID of the host database file as stored 
5 on the long term storage (e.g. hard disk drive) of the host 

computer, e.g. "My Calendar"; 

4) Name or ID of the remote computer; 

5) Name or ID of the remote database application; 

and 

10 6) Name or ID of the remote database. 

Therefore, the remote segment and the host segment ensure 
that the host history file have the same name. Moreover, 
each of the history files have the date and time stamp of 
q the previous synchronization. The remote segment and 

^0 15 synchronizer use this to ensure that the history files from 
j= the same previous synchronization of the two databases are 

used. 

^^f av - ing deacri feed^-jrn- geiieidl l^erTia ^ ^ 
by the r^n^te^gmerife-4fr^ the Synchronizer 

in response to tiTe~i"n"stxuct^ 2 in 

steps 404 and 409 (Fig. 4), we will now describe iTr^detail a 
fir^^ operation for the case where the 

rfmote database assigns unique ~IDs~~t-o— i-fe-s^^ecords . We will 
do so in reference to Figs. 5 and 6. 

Fig. 5is_Jth-e-- ps-eudocode^f or steps taken by the 
remote segment i n re op enrse t o -feh^^insJir^jgtion by control 
module in step 4 04 to load the remote database recoxds ^into 
th^-4i€^tr^ofkspace (Fig. 4) . The remote segment first 
initializes (i.e. creates) a remoe^work^^a^e^Jji_tl^ remote 
3 0 c ompu t er^(st^^^ he 
na*ae= :: ^£--^eHrost:— h±s1:^^ remote 

hist qry__JLil&— i n— tite— r emote - c oTnput-ex- I-f— trhe-H^me^e^3e^men t 

3— a— remat-e-ii-irs-trary— f-rl-e— t^hB't~ma't■ch^•s~t-heH^s^l^i5_tory 
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f .i.L@— .( i.e. — a— jf emoto hictory f i le th at matches hasp 




5 file ma^tc^ host history file (step 503), 

then c ghe remote segme n t dfir.p rminpg t hat two hi story files 
cpr^e-sp on'dr"£o" one another . Hence , the remote"~~segmenF^to ads 



10 on the remote and host computers, the remote segment 

transfers all remote database records to the host computer. 
Therefore, if the name of the host and rempte history files 
match but the date and time stamps do not match <(step 505) , 
then the remote segment assumes that remote history file is 

15 not the correct remote history file to be used. The remote 
segment removes that history file (step 506) and transfers 
all remote database records to the host computer (step 507) . 
If no remote history file matches the host history file 
(step 508) , then the remote segment assumes an appropriate 

20 remote history file does not exist. The remote segment 

transfers all the records to the host computer (step 509) . 
To transfer all the records in the above steps, the remote 
segment first loads and stores all records of the remote 
database in the remote workspace. The remote segment then 

25 transfers all records in the remote database to the host 

segment. If remote segment transfers all the records of the 
remote database to the host segment in either step 504 or 
509, then the remote will go to step 528. It should be 
noted that the host segment will use the host history file, 

30 if one exists, to perform the synchronization. 



conditions of steps 501 and 504 are satisfied - the remote 
history file is loaded into the work space.. It is then used 




If an appropriate remote history file exists - i.e. 
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to "filter" out information that need not be sent to the 
host segment since it already exists on the host segment. 
Generally, the history files on the remote and history files 
are used to store information representative of the remote 
5 database at the end of the previous synchronization. The 
records of the remote history file in the first embodiment 
contain the unique ID of the records and hash numbers of 
those records at the completion of a prior synchronization. 
In other embodiments, the remote history file may contain 
10 some or all of the field values of the records of the remote 
database . 



such as a string of characters, into a more compacted 
format, such as a number, meant to represent that string of 



15 characters. It may be considered to be a content-based 



encoding technique. The hashed values may be used as a 
surrogate for a hashed string of characters, for example, to 
compare strings. An example of a hashing algorithm is to 
calculate the following sum for every characters in a 



where character is the number stored in the memory to 
represent that character (e.g. an Ascii value) . (It should 
be noted that there are many ways of hashing data.) At the 

25 end of the computation, sum contains the hash number for 
that string of characters. In the described embodiments, 
the hash number is a 32 bit number and therefore can have a 
value between 2 32 different values. Because the expected 
number of records is much less than this number, the 

3 0 probability of two different records having the same hash 
value is small. Therefore, hash numbers can be used to 
perform comparisons instead of comparing the non-hashed data 
or a preliminary check before comparing the data, with 



Hashing may. be described as converting any data, 



20 



character string: 

sum = character + (31 * sum) , 
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relatively low risk inaccurate comparison. We have also use 
hash numbers as a unique identification code, which will be 
described in the second embodiment . 

The remote segment uses the remote history file to 
5 determine whether a record has been changed, deleted, or 
added since a previous synchronization. Therefore, for 
records that are unchanged, which typically constitute the 
majority of records in a database, the remote segment sends 
information that the host segment can use to identify the 

10 matching records in the host history file. That matching 
history file record contains the same data as necessary to 
use for synchronization as that on the remote database since 
the record is unchanged. Therefore, there is no need to 
send the whole record. In essence, the remote segment uses 

15 the remote history file to filter out information that is 

already contained in the host history file and sending only 
those records that have been changed or added. In some 
embodiments, the remote history file may contain all the 
field values of the records of the remote database. In 

2 0 those embodiments, the remote segment can determine not only 
which records have been changed but more specifically which 
field values have been changed. In that case, the remote 
segment can determine and then send only those field values 
that have been changed, further increasing the efficiency of 

25 using the slow data transfer link. 

We will now describe this process in detail. In the 
described embodiment, for each record of the remote database 
(step 515), the remote segment loads the field values, 
including the unique ID, of the record into the remote 

30 workspace (step 512) . As the records are loaded, they are 
translated (e.g. "translated" as described in the '390 
patent) into a universal format for the remote workspace. 
The records will be translated back into the format of the 
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remote database as they are written into the remote 
database. The remote segment also computes a hash number 
based on all or selected (e.g. the fields to be 
synchronized) field values (step 513) . In the described 
5 embodiment, the hashing number is a 3 2 bit number. The 

fields on which the hash number is based on remain the same 
for all synchronizations relying on this remote history 
file. The host segment also performs a hash on the same 
fields. If the fields which are hashed changes, the hash 
10 number of unchanged records would not remain the same from 
one synchronization to the next. 



record was present during the previous synchronization. 
15 That record could either be a changed record or an unchanged 
record. If the computed hash number for the record matches 
the hash number of the record in the history file (step 

516) , then the remote segment assumes that the record has 
not been changed since the previous synchronization and 

20 therefore can be created by the host segment from the host 
history file. The remote segment will take no action (step 

517) . In other embodiments, the remote segment can send the 
unique ID and a flag indicating that the record is unchanged 
to the host segment . 

2 5 If the computed hash number does not match that of 

the history file record (step 518) , the remote segment 
assumes that the record has been changed since a previous 
synchronization. Therefore, the remote segment sends the 
host computer the field values including the unique ID and a 

30 "changed" flag (step 519) . In some embodiments, only those 
field values that have been changed since the previous 
synchronization will be sent, as described above. The 
remote segment then creates a new entry for the changed 



If the unique ID matches one of the unique IDs of 
records in the remote history file (step 515) , then the 
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record in the history file (seep 520) and marks the record 
as unacknowledged (step 521), the purpose and function of 
which we wil^l^now briefly describe and is also described in 
s/W 6!? the ^^^926^ 1^ ' 645 applications. 

QfV§ Generally, the remote segment does not change an 

entry in the remote history file, until it receives an 
instruction indicating that the host segment has 
synchronized and updated the host database with that record. 
This is done so that if for any reason (e.g. user does not 

10 want to update that record of the host database as described 
above) the host database is not synchronized with that 
record, the remote segment will not treat that record as 
unchanged during the next synchronization. The 
acknowledgement may take the form of an "acknowledgment" 

15 flag or an "action" instruction which instructs the remote 
segment to add, update, or delete that record of the remote 
database, as described above. Therefore, for each changed 
and deleted record, the remote segment creates a new entry 
and marks the entry as "unacknowledged" . If an 

2 0 "acknowledgment" flag is received, the old history file 

record is deleted. If an "acknowledgement" flag is not 
received, the new workspace entry is deleted. The seeps 
will be described further below. 

If in step 515 the remote segment determines that 
25 the unique- ID of the loaded record does not match any of the 
unique IDs stored in the records of the history file (step 
521) / the remote segment assumes that, the record loaded from 
the remote database has been newly added. Therefore, the 
remote segment sends the host segment a copy of the field 

3 0 values of those fields of the record to be synchronized 

(which may be all or less than all the fields) together with 
an "added" flag (step 524) . As in the case of a changed 
record, the remote segment creates a new remote workspace 
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entry and enters the unique ID and hash value of the record 
(step 525) . The new entry is marked as unacknowledged (step 
526) . 

After all the records have been loaded (step 528) , 
the remote database determines that unique IDs in the 
history file that have not been matched represent the 
deleted records (step 529) . Therefore, the remote segment 
sends the host segment those unique IDS together with 
"delete" flags (step 530) . 

-A££- e r the remote s e gment ha ^-^ inis^ 
th^host-segmeTXtr; ElTeTiost segment synchronizes the two 
databases based"" on Lhe input f rom -JJna_x^mote_se g^ . The 
remote segment waits un±JJ;__tJa^^ 
syTLchren-irzlng and instructs the remote- segment in step 40 9 
"^tnr-Fig-, — 4- to b o gin r-tm^u ddiiig into L he ~remot'e— database — (-step 

The host segment synchronizes the two database 
similar in the way it synchronizes a so-called "fast 
synchronization" database (as defined in the '490, '926, and 
'645 applications) with another database. The operation of 
a synchronization program synchronizing a fast 
synchronization database with either a fast synchronization 



database or a regular database (i.e. non- fast 
5(2^/0^ synchronization) is described in detail in the 



30 



aftdr^ 64 5 . We will now describe in detail how the 
information from the remote segment is used to synchronize 
the remote database with another database. 

As described above, a remote segment sending remote 
database records to the Synchronizer provides field values 
of only those records which have been changed or added since 
the previous synchronization but not those records that are 
unchanged or deleted. Therefore, unlike a regular database 
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Translator, the remote segment does not provide the 
Synchronizer with unchanged records. 

In order to synchronize the remote database with the 



host database, the Synchronizer transforms information from 
5 the remote segment into regarding unchanged records into 
equivalent regular database records. These transformed 
records are then used by the Synchronizer in the 
synchronization. Essentially, the synchronizer transforms 
and uses the information sent by the remote segment to 
10 identify a record in the history file that is a copy of the 
field values of the unchanged remote database record. In 
the described embodiment, the synchronizer also copies that 
history file record and flags as being the remote database 
Q record. 

^fl 15 The described embodiment uses the host history file 



to perform this transformation. At the beginning of a first 
synchronization between the two databases, all records in 
the remote database are loaded into the host history file. 
As changes, additions, and deletions are made to the remote 



. of each synchronization will contain a copy of the relevant 
content of the remote database after synchronization. By 

2 5 relevant, we mean data in the fields that are synchronized. 
For example, it may be the case that the host history file 
contain data in fields that are not synchronized. Moreover, 
if the records of the remote are mapped or recast into 
another format (e.g. "translated" as described in the '390 

30 patent) the records of the history file contain a copy of 

the records of the database, as mapped, translated, or both. 
The Synchronizer uses the mapped or translated records for 
synchronization. Therefore, it only needs the mapped or 



m 2 0 



database, during each subsequent synchronization, the same 
changes, additions, and deletions are made to the host 
history file. Therefore, the host history file at the end 
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25 



translated copy of the unchanged record. In other 
embodiments, the host history file may contains copies of 
all the records exactly as they are in the remote database 
or in some other format that is useful for the particular 
application. 

. Re f e rrin g t u Fi g": in t hH^desg^b.c d _c mbod-i-menJ^ 
all records receive^J^y-^ii"ehost segment from the remote 
s egme gt^-axe^T lagged with one of Added, Changed, or Deleted 
flags. For all reconis"lFe^ segment 
10 (step 601) , the host synchronizer performs th^^Sl~irewing 



p ■ functions. If a received^ecord_i 

record (step 602J w ----teh;eri the received record is added to the 
host w orkspace (s tep 603) . Since the record is new, it is 
not associated or linkedHEo^an^^ record. If a 

15 record is flagged as a "changed" record (step^S^4JL- then the 
Synchronizer uses the received unique ID to find the 
corresponding record in the history_fjJ^_jLsJtep--6^5^ and 
links the receLved— rem&te record to that history file record 
(stepCgflg TT^^If th e received record is flagged as a 
"deleted" record (step^^oTTT"^^ uses the 

received unique ID to find the corresponding recor?Sin the 
history file (step 608) and marks the his tory_f ile_gacQ3fd as 

deleted ( st^p^609j_--— ~~ 

cfter all the received records are analyzed (step 
6lTT~, — irf-any"' host history fi^er-reeoxds_containing remote 
database unique IDs are left that were not matche^aqainst 
the received records, the synchronizer assumes that thos* 
records repreaente^he~~Tenrote database records that are 
unch anged. For all those re cords (step 612) , the 
30 synchronizer clones the host hist^oryT±i«-^@cor^ 

create a workspace entry ancL-Cjopy_al l the host hij ^&rv^file 
rec^^^LrT^ and treats it as a record received 



from the remote database, 



At this point the 
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procee ds with byaclir onization since th^recoras^of— cii5^ 
remote dataiDa^se^ In essence, referring 

back" Lo Fig- — 4^--^±Li^J 1 £__£h^ end of step 404. 

As previously described^ aflfeT~~trh^---syn£y^^ has 
performed CAAR, the^j^erjnu^ proceed with 

updating the^jiemofe database (step 406 in Fig. 4) . If the 
user r VrffMripfi m r eLrnxlrt^t^-^^ changes are 

not made to the host history f i 1 ^eor~~t^ he 
case of the remote_^tabaeer - ^s' - aescrTSea in reference to 



10 Fig. 5 f ^&he*^femote segment is waiting for the synchronizer 

rrC^fTnish s ynchronizinQ . If the_ jaser aborts synchronization 
(step 533) , the remote segment discards the^efnot^jvorkspace 
(step 534) , saves the original history file without any 
changes (step_5J5-)-,— arnd^-ermira 
^compu^x^""^ 

iser confirms to proceed with updating the 
database (step 406 in FigTT) T^rof^^rx^^jnodule 2 instructs 
the synchronizer and the remote segment to pn5^ed^ith 
unloading the records from__^e^wo-r3csp 

database^^As-stated, at this point, the remote segment is 
wa iting for the synchronizer t ofinish synchronizing (step 
5 32 in Fig. 5) . During the synchronizatrorirr-th^^^ 
synchronizer has determin ed what "actions" with resp ect to 
whi5h-reoo"fa in which database should be taken (update, 
ctebete, or add) ro___cjomplete synchronization. If changes or 
additions are made to theli<^ of 
particular record but no action need be taken wi^t^respect 
to that r^GerdHnr-ttter^ 

det ermines t hat an "acknowledgement" should be sent to the 
3 0 remote segment . The synchronlz^^ef^s^allthe actions 

conc.erning-the— remote-da tab.ase_toget^ i a t ed 

C record to the remote (step 616) . The synchronize*— then 



20 



25 



sends the unique ID of those records tKat— require^ 
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ackno>J.•edgefnen1r5^ , to be senc co tne^^^moJLe—togeG-h-e-r- -witfesan 
appropriate f Lag_Xsferep-^I 

Referring again to Fig. 5, for each action item or 
acknowledgement receiv"e"dr^fc-^e^rjg^ (step 538) , 

the following steps are performed. If the rece-i-ved data 
indicates an '^acknowie^^ a 
record^tha-fer-was added or changed since the previous 
syncKroMrza±-i-on- — &he—re.mote segment marks the new workspace 
entry that was created in either step 520~~~~or— s.fce_g52 5 as 
acknowledged (step 540) . The remote segment also disj ^ards 
or removes any^Q&her^tV&r^ that contains 

tS^^nique ID of this record, which is typically the entry 
that was loadfeT±-*r©H^^ file. Therefore, as 

previously described, this entry as opposed to the old 
remote history, fileerrt ry associated with M^hls^ will 
be written^into'^he history file at the end of the process 
fhe remote segment. This in essence updates the history 



file, as will be describedT~B 

If the received data indicates an act^^on^item that 
tells the remote segment to update, change, or add a remote 
^^abe^e^ecordT^step 543) , the remote segment performs that 
action with respect to the remot^-da-tal^ase. The remote 
segment also performs the same steps as steps^i^^nxi 541 
(step 544 and 545) . If a new record was added to the 
database ( s tep 546) , it will be assian ed_a_new_JLinlqu^ 
The~<rg^ sends rliat^jinlque ID to the host segment 

(step 547) . The host segment includes~^^ ID in the 

host work space in association with that recorct^step 618 in 
6) . 



Fig 




ter all the records have been recei ved., the re mote 



segment discards^alljinack-R©^ irom che 

u/nrlc-g-pace^ """"Thare^osre-; — a^r-t-he— eas-e— o-f— thos_ e added or changed 



"withwhich the user decidednot"""Eo"^2pda*^ 



• # 

d a t aba se-, — fcfa^~-gemefee-4rirs tory fil e— remains unc hanged^ £he 

r emo-t^e^hisJtox^C-fll^ he i emo te" 

wor k'spaee- At^fehis— poi-ntr-tiie^on^^ t h 

s t e p"Tro"in Fig"! 4~ i.e. creating CtiB~h±s-trOi^y~- jhi-i-e—trcr~eTTa" 
the synchronization of~The two databases. 

In the first embodiment, which we described above, 
the remote database assigns unique IDs to its records. We 
will now describe a second embodiment for the case where the 
remote database does not assign unique IDs to its records. 
In such a case, the remote segment provides some information 
less than all the fields of the records to uniquely identify 
an unchanged record to the host segment. This information 
may be a hash value. The host segment uses this information 
to find and then use the host history file copy of the 
unchanged remote database record to synchronize the two 
databases. 

To identify a record from the previous 
synchronization or an unchanged record, the remote segment 
can use a content based code, that is a code whose value 
depends on the content of all or a selected number of the 
fields of a record. In the second embodiment, the remote 
segment uses hash numbers. Since in the case of an 
unchanged record, its content has remained the same, its 
hash number remains the same. The hash number acts as a 
unique identifier and therefore enables the remote and host 
segments to identify the unchanged record by its hash code. 
The hash code can be used to identify a record that is 
stored in the host history file, since its content remains 
the same from the end of one synchronization to the time it 
is updated. It may also be transmitted to identify an 
unchanged record or an unchanged version of a changed 
record. A host history file record can in effect be 
identified using the hash code of that record. 
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will describe tne operatiorT" u£ this cmbod-irmen^-in 



refe renc e Lo ~Figs. / and 8. ""St ^ ' ps 701 -7ir ~are""~the samg~~3^s 



firs-e— embodiment ". There- otcp3 a ge— g enerally cotrc ggheci with- 
r^iftdiftg— the correct remote history ~foT3re . 

After determining that there is a suitable remote 
history file, for each record of the remote database (step 
712) , the following functions are performed. The remote 
segment loads and translates a record of. the remote database 
into the remote workspace (step 713) and a hash number is 
calculated for that record (step 714) . If the hash number 
of the remote record matches one or more hash numbers in the 
remote history file (step 715) , then the remote segment 
assumes that the record has not been changed since a 
previous synchronization. 



more than once, e.g. because of duplicate records or records 
that appear as duplicates because some of their fields are 
not synchronized. Therefore, the remote segment sends 
additional information that can be used to identify which of 
the multiple identical hash numbers a particular record 
relates to. This is done because during updating the remote 
history file record at the end of synchronization, the same 
number of identical hash numbers as matching remote database 
records are updated. In the second embodiment, this 
additional information is the index number associated with 
each entry of the remote workspace. Therefore, when the 
hash number of the remote record matches one or more hash 
numbers in the remote history file (step 715) , the remote 
segment sends the hash number, a flag indicating that the 
record is unchanged, and the index number of that hash 
number to the host segment (step 716) . Obviously if the 




It is possible that the hash number may be repeated 



# 



index number was previously sent, the next index number for 
the identical hash is sent. 

If the hash number does not match one or more hash 
numbers in the history file (step 717) , the remote segment 
5 treats that record as having been newly added. Therefore, 
the remote segment sends the host segment a copy of the 
field values of the record, the remote workspace index 
number, and an "added" flag (step 720). The remote 
workspace index number makes it easier to perform future 
10 search of the remote workspace when data with respect to 
this record is received. As in the case of changed and ■ 
added record in the first embodiment, the remote segment 
also creates a new remote workspace entry and enters hash 
□ number value of the record (step 718) . The new entry is 

15 marked as "unacknowledged 11 (step 719) . It should be noted 
£ that although the remote segment treats the record as a new 

5 record, the remote segment can not distinguish between an 

.,5 — 

5 added and a changed record. Therefore, the synchronizer 

W during synchronization does not treat it as a new record. 

« 20 Instead, the synchronizer compares the record to determine 
whether it matches with any of host history file record 
which would mean it is a changed record. 

After reading all the remote database records and 
processing them (step 722), the remote segment removes from 
25 the remote workspace all entries that have hash numbers that 
are unmatched (step 72 3) . These entries represent records 
that have either been changed or deleted since the previous 
synchronization. 

After th e-3 femote s egme nt has f i ni sh ed-^govidtng darta 
3^ 3^^^^^ Lhe host segment synchrontzes tne two 

databases bas e d on th e i nput fium the le rnoLe seymen^ — ^Ehe 

rcmsre— ^ gm^nr wait-g nnfil Mia ho s t s eg ment finish es ~ 

sy nchronizing a jid^Jj^s-tx*^^ 409 
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in_ Fiq. 4 to begin unloading into the- n emnto-finr n h ase — Cs£ 

724) . " 

±jng to Fig. 8, as in the case of the first 



embodiment, the synchronizer on the hos 



er uses the 




information to identify_jtho&e-* records in the host history 



file that^oe-rrespond to the unchanged remote database 
records"! FQ*r~every— r^csrdreceived from the remote segment 

,that is flagged as added (step80Tn tfee-~-^ynchronizer adds 
the record to the host workspace (step 802) andHtrriiig CAAR 
compares the record to the history file to determine wh^her 
the recx^ For every record 

<£^5§lvedfrom the remote segment that is flagged as 
"unchanged" (step 8 04) , xn ttxe~-sa:me-maiin^ras the first 
embodiment, the synchronizer finds the corresponding host 
history file record by finding a record that has the\$ame 
hash number as that sent by the remote synchronizers-step 
805) . The synchr_oixi~^^ 806) , 



^s-^^eviously described, and treats as if it is a record 
received from the remote lliTrab-as-e — ^Atthe end of this 
process, when all the records of the remote^d^t^base are 
loaded into the host workspace, the control module>^ ceeds 
t^_srep--4^S--irrFig. 4 to begin CKKEC. — CSfcR-will thefianalyze 
the records in r-fe&e-JiQ£_t_^ to determine which remote 

records were added, which were~cHangedr> — ai^d^which were 
deleted since the previous synchronization. 

Aft^rLJZAABr; — i-f— tire - user conrirms to^proceed with 

pd a t i ng th e databa s e -, c&n__Lrol L module 2 instructs the 

synchronizer and the remote segmen^TTO^roceed with 
unloading the records from the workspace into TJhe. remote 
database— fstep"~409 m Fig. 4) . as stated, at thrs 
■t-ke- romotc o - e g meiiL is waiLiiiy f o r tho — s 
synchronlzjmg_^^ Tj 
_the syn ^^ni 7 ^ ^k-*-*^^ actions shoulcTgg--frakgn^ 
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(upda-ke-r — delete., or-add-) — to— eax: tr~Sa~tra has e_^_J z £Zc^n^^o r 

additions are made_ts^h«--hostr~^^ case of a 

partseuTax-^re.CQr d but no naction need be taken with respecc 



to that record in the remote databasST^fefe-e^synchronizer 
5 determines that at least an M acknowledgement ''"^is^t^^be sent 
to the remote sejfment^ sends all the 

actions^oneerrfing the remote database together with the 
a#soc±atredr-*^©-rd-^ index to the remote 

(step 809) . The synchronizer then sends^The-^r emote 

10 workspace index of those^ecords_£h 

acknowledgernen-t-s—to^be sent to the remote together with an 

<; ^app"ropriate fla g (step ,_8 JLQ_L !Haere ; £g r^_the _ r emo t e 

workspac^^^ which records in the 

remote workspace should be "acknowledged" . 

15 -Refe rring back to -Fxg": /, ■steps_J725_r7Z9 ^ 

as steps 532j^53i^wbich^ in reference to the 

firSE^e^odiment . For each action item or acknowledgement 
received a/tTThe~~r^^ — (^e£_J730^^tl^ following 
steps are performed. If the data received lndireart^eS^an 

20 "acknowledgement" or "actiorv^j^it^ 

was sent to the^feost-^segment flagged as "added" (step 731), 

^? tlge^relnot^seg ment marks the new workspace entry that was 
cr^atec^^ 7 32) . It 

should be noted that the remote workspace index^number is 

2 5 used to locate theremote^o;i^ TKerefore, as 
^-^previim^ry^aescr^ed, this entry will be written into the 

s^egmerrtrr" 

If the received data indicates an action item that 

3 0 tells the remote segment to update, change, or add a remote 

database record (step 733) , the remote segment performs that 
action with respect to the remote database. The remote 
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segment also updates the remote workspace and marks the 
entry as "acknowledge" (step 735) . 

^ ^ Af tcr -^ a - 11 th e r e co rds" have been'"recg ±veeh — fe fae^remot e 



segment discards^all^ entries from the 

5 workspace, — whrch were newly created entries which were not 

acknowledged-: There-fore- — i-n— ea-se-o-f^_tiios_eadded or changed 

records with the user decided no t^ to update theK&s 
database wrth^the— remote history file remains unchanged. 
Ther-r^mote history file is then updated from the workspace. 
10 At this poin^^ 410 in 

Fig-.-— 47 i.e. creating the history file to end the 
^-synchron i zLajt±on— q f t h o t wo— d-a-t-a-fa a-s-e-s-^ 

Although we have described embodiments in which the 
host segment transforms the input from the remote segment, 
15 it should be noted that other embodiments of the host 
JE segment may not transform the input from the remote segment 

D since they are designed to use inputs that informs them of 

K which records have been changed, added and deleted or have 

IjJ been left unchanged. Other embodiments in which the host 

L 2 0 segment requires different types of input, the input from 
J= the remote segment are transformed as required. The various 

jj^ embodiments of the host segment may or may not use a history 

£ : = 

3 file. 

1= Other embodiments are within the following claims . 

2 5 What is claimed is: 
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